In a network switch ASIC (Application-Specific Integrated Circuit), L2 packets are switched based on a lookup on a L2 hardware (HW) address table. Such a L2 HW address table is hereinafter referred to as a L2 table. L2 hardware refers to a network device (e.g., a switch) that forwards traffic based on MAC (Media Access Control) layer addresses (e.g., Ethernet or Token Ring addresses).
A L2 address table includes entries for one or more network devices (i.e. L2 hardware such as, for example, a switch). Typically, each entry in the L2 table includes source MAC address information, VLAN (Virtual Local Area Network) information, and source port information. Because table look-up and L2 switching functionalities are performed by L2 hardware, it is important to have a source L2 address learned (or programmed) on the L2 table for each of such L2 hardware. Otherwise, if the lookup fails, the packets destined to that source L2 address would be dropped or flooded out to multiple ports.
Due to the limited size of memory (e.g., telecommunication access method (TCAM) or communication access method (CAM)) of a network switch ASIC, the size of a L2 table is usually limited to 16K or 32K entries. Furthermore, a hashing algorithm is used to manage (e.g., compress) information used to access contents within the L2 table in a manner that provides for faster accessing (i.e., look-up) of such contents. Hashing is the transformation of a string of characters (e.g., the MAC address) into what is typically a shorter fixed-length value (i.e., a key) that represents the original string. It is advantageous to use hashing for indexing and retrieving contents of a hardware address table (i.e., table entry information) because it is faster to find such content using the shorter hashed key than it is to find this same information using the original value. Because of the nature of the hashing algorithm, particularly hash collision and the depth of the hashing bucket, there are instances in which new entries cannot be added to the L2 table. For example, as shown in FIG. 1, a plurality of L2 packets are received from each of three different MAC addresses (i.e., MAC address A, MAC address B, and MAC address C). For each of the packets, a respective key is retrieved (e.g., its MAC address) and is used in deriving a respective index. The objective is to store contents of each packet (e.g., source MAC address information, VLAN (Virtual Local Area Network) information, and source port information) in a L2 table in paired combination with the respective index. In this manner, contents of a respective packet can be accessed within the L2 table though use of the key of the respective packet. However, as can be seen in FIG. 1, MAC address A, MAC address B and MAC address C all have the same index (e.g., index “120”) and, thus, exhibit hash collision. It can also be seen that the size of the hash bucket is 2 (i.e., 2 entries). Accordingly, the contents of the packets from MAC address A and MAC address B are added to the hash bucket (i.e., added as L2 table entries), which was previously empty. The contents of the packet from MAC address C, however, cannot be added because after adding the contents of the packets from MAC address A and MAC address B, the hash bucket is full.
A problem that exists with current (i.e., prior art) implementations of managing L2 tables is that there is no consideration of packet priority when it comes to adding an entry to the L2 table. Thus, in the case of the example discussed above in reference to FIG. 1, the contents of the packets from MAC address C are not learned (i.e., stored in the L2 table) even if the packet priority of packet from MAC address C is higher than that of MAC address A or MAC address B. The situation is further complicated if MAC address C is a router MAC address or an address of a server because the network device corresponding to MAC address C will be unknown to an associated network switch ASIC, resulting in all the packets destined for the network device of MAC address C being flooded.
Therefore, facilitating management of a L2 hardware address table in a manner that relies upon packet priority information will overcome drawbacks associated with conventional (i.e., prior art) approaches for facilitating management of a L2 hardware address table and, thus, would be advantageous, desirable and useful.